1. Field of the Invention
The present invention relates generally to digital logic simulation and emulation and, more particularly, to systems that stimulate a physical digital logic device included in the simulation or emulation, and retrieve responses produced by the stimulated logic device.
2. Description of the Prior Art
Various different software and hardware systems exist for simulating and/or emulating digital logic systems. An example of a widely used software system for simulating digital logic systems is an IEEE standard simulation programming language called Verilog. Various vendors, such as Cadence Design Systems of San Jose, Calif., offer compilers or interpreters for the Verilog simulation language. Software digital logic system simulators, such as Verilog, are routinely used for designing systems as physically small as individual integrated circuits ("ICs"), and for designing much larger digital logic systems that include numerous ICs.
Performing a Verilog simulation requires that a digital logic designer employ a computer program model for the system by aggregating into a simulation computer program various software modules. The software modules making up a Verilog model include modules for each digital logic circuit included in the simulation, for specifying interconnections among the Verilog logic circuit modules, and for specifying timing relationships among the interconnected Verilog logic circuit modules. It is readily apparent that preparing a simulation computer program for a digital logic system that includes numerous ICs is a herculean task if the designer(s) must individually write Verilog modules for each digital logic circuit included in the system.
Since in almost all instances IC manufacturers simulate their designs before fabricating even a prototype, in principle a simulation model exists for each IC that is left over from the IC's development. Moreover, an IC manufacturer probably retains that simulation computer model for maintaining, fixing and enhancing the IC's design. However, because an IC's simulation model reveals details about the IC's design that manufacturers would prefer not revealing to actual or potential competitors, IC manufacturers rarely, if at all, make available to designers of systems that use the IC the simulation computer model developed in designing the IC. Moreover, even if the simulation computer model used for designing the IC were available, it would includes details about the IC's operation that are unnecessarily complicated for designing a digital logic system that incorporates the IC as a component part. Consequently, using an IC's design simulation computer program in simulating a larger digital logic system that includes the IC would, in most instances, produce simulation results no better than those obtainable using a much simpler simulation model for the IC, while at the same time markedly increasing the amount of computation required to simulate the larger digital logic system.
Some manufacturers, generally the larger ones, make available to system designers simplified simulation modules for their IC products. There also exist vendors, frequently unrelated to an IC's manufacturer, who provide designers of digital logic systems with a simulation model for a specific IC, and/or libraries of simulation models for simulating a number of different ICs frequently from a number of different IC manufacturers. Even with these two possible sources for simplified IC simulation modules, they are unavailable for some ICs because their manufacturer's, generally smaller ones, do not develop them in a timely manner, and the products do not sell in sufficient volume to attract development of simulation modules by independent companies.
Regardless of the source, simplified simulation models may not faithfully reproduce the IC operation, e.g. simplified simulation model may contain latent bugs. It is readily apparent that a simulation model which contains a latent bug may appear to produce correct simulation results when used in simulating some digital logic systems, while producing incorrect simulation results in simulating other digital logic systems. Moreover, if a simulation model is not available for a particular IC, then the designer of a digital logic system that includes the IC must write such a simulation model with the attendant risk that the computer model will be insufficiently faithful in reproducing the IC's operation.
In addition to software digital logic simulation, various vendors, such as QuickTurn Design Systems of Mountain View, Calif. and Ikos Systems, Cupertino, Calif., offer hardware systems for emulating digital logic systems. An example of such a hardware simulation system is a Avatar.TM. emulation System offered by Ikos Systems. An Avatar emulation system divides a digital logic system, perhaps specified by a Verilog structural netlist, into separate parts which are then individually processed for configuring several Field Programmable Gate Arrays ("FPGAs"). The Avatar emulation then configures several FPGAs and suitably interconnects the FPGAs input and output pins to emulate the digital logic system.
One problem encountered in using FPGAs, either as configurable application specific integrated circuits ("ASICs") or in simulation or emulation, is that a significant amount of time is required to prepare a bit stream needed to configure the FPGA. The conventional way to prepare a FPGA configuration data file uses a technique referred to by those familiar with FPGAs as "place and route." While computer programs automate the "place and route" process for preparing a FPGA configuration data file, configuring a single FPGA using conventional "place and route" computer program may require several to tens of hours of computer time. Moreover, the conventional "place and route" computer program technique cannot guaranty producing a bit stream that will surely configure the FPGA for its intended purpose upon terminating the program's time consuming computation. Clearly, it is impractical to use a technique as cumbersome as the conventional "place and route" process for IC simulation or emulation if a dozen, or even one-half dozen, FPGA's must be configured before performing each simulation or emulation.
In addition to the polar opposites of digital logic system software simulation and digital logic system hardware emulation, there also exists intermediate systems that employ a hybrid of hardware and software for digital logic emulation or simulation. An example of a software-accessible, hardware IC emulation is called an in-circuit emulator ("ICE"). ICEs are commercially available which emulate a particular IC. In general, however, an ICE includes the physical IC that is being emulated, and adds to that IC additional circuitry which permits software monitoring of the IC's operation. Consequently, ICEs are comparatively inflexible, and there does not presently exist a general purpose ICE that will simulate any IC for which a simulation model exists.
There also exists another type of hybrid hardware and software system which incorporates a hardware IC model into a software digital logic simulation. An example of such a hardware IC model system is the ModelSource system marketed by Logic Modeling Group of Synopsys ("Synopsys") of Mountain View, Calif. To incorporate a hardware IC model into a digital logic simulation using the ModelSource system, a logic designer must plug an IC mounted on a special purpose adapter board into a ModelSource system. A ModelSource processor, such as a workstation, interconnects the ModelSource system to a local area network, such as an Ethernet, over which the ModelSource workstation communicates with another workstation which runs the simulation computer program. During the simulation, if a change occurs in a signal that is applied to an input pin of the hardware-modeled IC, the pin change is transmitted via the local area network to the ModelSource processor. The ModelSource computer program running on the processor formats the pin change for the ModelSource system and transmits it to that system. The ModelSource system then presents the pin change to the IC and senses any change which occurs in a signal present on an output pin of the IC. The ModelSource system then returns the output pin changes plus the corresponding timing information to the simulation computer program via the local area network. Various aspects of similar systems which incorporate a hardware IC model into a digital logic simulation are disclosed in U.S. Pat. Nos. 4,590,581, 4,635,218, 4,744,084, 5,146,460, 5,353,243 and 5,369,593.
Another example of a hybrid hardware and software system which incorporates a hardware IC model into a software digital logic simulation is disclosed in U.S. Pat. No. 5,748,875 entitled "Digital Logic Simulation/Emulation System" that issued May 5, 1998, on an application filed by Yiftach Tzori ("the '875 patent"). The system disclosed in this patent includes a hardware pod having configurable-logic ICs arranged to provide a plurality of stimulus/response cells which are coupled to a digital logic circuit. Similar to the Synopsys ModelSource system, the hardware pod is itself coupled to another computer that executes a computer program for a simulating digital logic system, such as a Verilog simulation computer program. During a stimulation-response cycle for the digital logic circuit, as specified by data received from the digital logic system simulation, the stimulus/response cells apply stimulus signals to the digital logic circuit, and receive response data from the digital logic circuit for transmission back to the digital logic system simulation.
The '875 patent discloses that the stimulation-response cycles of hardward pod of its hybrid hardware and software system are performed in lock-step with the software digital logic system simulation. That is, the digital logic system simulation computer program executes without communicating with the hybrid hardware and software system until such time as the simulation computer program must stimulate the digital logic circuit and receive that circuit's response to such stimulation. When the simulation computer program reaches such a state, it transmits data specifying the stimulation to be supplied to the digital logic circuit, and then pauses any processing that requires response data from the digital logic circuit until receiving such data. In many instances, lock-step synchronization between the simulation computer program and the digital logic circuit's stimulation-response cycles unnecessarily increases the time to perform a simulation.
In addition to simulating an IC, a converse situation arises in which a simulation model exists for a particular IC, but the IC itself is not available when a digital logic system designer wants to begin implementing and testing a digital logic system which incorporates the IC. Alternatively, even though an IC is available for use in implementing and testing a digital logic system's design, analogous to the use of an ICE in designing and debugging a digital logic system, a designer may want or need to observe and monitor the IC's interaction with other circuit elements, such as other ICs. Under either of these circumstances, a digital logic system designer may find it desirable to introduce digital logic signals into an implementation of a digital logic system that represent results obtained from a software simulation of one or more ICs.
In addition to a requirement to simulate or emulate an entire IC, there also exists a need to effectively and efficiently simulate or emulate only a portion of an IC. Presently, there exist companies which sell or license designs that form only a portion or core of an entire IC design. For example, such a enterprise may have a design for a CPU that it wishes to sell or license to a second enterprise which then incorporates the CPU design into the second enterprise's IC design. However, before the second enterprise buys or licenses the first enterprise's design, the second enterprise wants to be certain that the first enterprise's design works properly, and is compatible with the remainder of the second enterprise's IC design. In theory, the first enterprise could easily satisfy the second enterprise's need to inspect and test the first enterprise's design by providing the second enterprise with a simulation computer program's source code for the first enterprise's design. Unfortunately, the first enterprise is usually reluctant to provide the second enterprise with the simulation language program's source code because providing that level of design detail may, and most likely will, divulge to third parties proprietary design techniques which the first enterprise employs, and which provide the first enterprise with a competitive advantage. One solution to the preceding dilemma is if the first enterprise provides the second enterprise with a net list for the design which contains all of the design's details without revealing the proprietary design techniques. Unfortunately, incorporating a net list representation of a design into a simulation usually yields an undesirably, or even unacceptably, slow simulation.